Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

[Huub van Helvoort <[e-mail]>]

All,

To me "vendor-specific" is synonymous to "proprietary"
and not agreed between multiple vendors.

IMHO "vendors-specific" or "vendors-specified" would be better
if "non-standard" is not used.

Best regards, Huub.

--------

On 23/10/2018 14:28, Daniele Ceccarelli wrote:

Hi,

 

i was basically identifying option 1 in which we keep on using “standard vs non standard” code points (i.e. ITU vs non ITU) and option 2 which allows further defining the non standard “group” into e.g. vendor specific, MSA, IA, open source etc.

 

If we go on with option 1 I would keep on using the terminology defined in RFC7581 (i.e. ITU application codes vs non ITU code points). If on the other hands you prefer to further specify categories for the non ITU code points, we can discuss about it.

 

The WG seems to be more or less equally split between the two options. I don’t have a strong opinion, both of them work for me. Probably further splitting the non standard ones allows for a cleaner allocation.

 

BR
Daniele 

 

From: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Sent: martedì 23 ottobre 2018 10:24
To: Jonas Mårtensson <[e-mail]>; Leeyoung <[e-mail]>; Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>
Cc: [e-mail]
Subject: 答复: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi,

 

I think we are converging with categorizing into “standardized” and “non-standardized”, we just need two terms on these.

 

For “standardized”, I would say “ITU-T G.698.2 Application code” is very explicit and will not have any misleading issue; it seems we don’t have other opinions neither.

For “non-standardized”, we have terms “vendor-specific” VS. “MSA/IA”. Personally I am preferring “vendor-specific”, which is implying it may be agreed by one or multiple vendors but is not standardized. I would not prefer using “MSA/IA”, as the standard (G.698.2 application code) is also a “MSA/IA”, which will be slightly misleading.

 

My 2 cents,

Haomian

 

发件人: Jonas Mårtensson [mailto:[e-mail]]
发送时间: 2018年10月23日 16:13
收件人: Leeyoung <[e-mail]>; Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
抄送: [e-mail]
主题: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi,

 

“My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct?”

 

I’m not sure I understand this statement/question. What is the alternative? The optics must come from somewhere, whether it’s a standard interface of not.

 

/Jonas

 

From: Leeyoung <[e-mail]>
Sent: den 22 oktober 2018 20:48
To: Jonas Mårtensson <[e-mail]>; Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi Jonas,

 

My understanding is that MSA/IA still uses vendor optics (component vendor). Is this correct? If so, I would create leaf-list of identifiers that apply to any non-G.698.2 application code. Would this work for you?

 

Thanks.

Young

 

From: Jonas Mårtensson [mailto:[e-mail]]
Sent: Monday, October 22, 2018 1:39 PM
To: Leeyoung <[e-mail]>; Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi,

 

I would prefer Option 2 but rename “Open source specific” with “MSA/IA” (multi-source agreement / implementation agreement).

 

I don’t see why this should be part of “Vendor specific”, also considering that the organizations I referred to earlier have multiple operator members.

 

/Jonas

 

From: Leeyoung <[e-mail]>
Sent: den 22 oktober 2018 16:39
To: Jonas Mårtensson <[e-mail]>; Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi Daniele,

 

Option 1 sounds better to me.  Perhaps rename ‘Standard ITU’ with ‘G.698 application code’ and ‘non-standard’ with ‘vendor-specific’. Open-source specific is a part of vendor-specific category. Have you consulted Deborah on this issue? It would be good to know the direction of the WG on this issue.

 

Thanks,

Young

 

 

From: Jonas Mårtensson [mailto:[e-mail]]
Sent: Monday, October 22, 2018 6:26 AM
To: Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Leeyoung <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Out of curiosity, what or who decides what can be considered a “standard”?

 

/Jonas

 

From: Daniele Ceccarelli <[e-mail]>
Sent: den 22 oktober 2018 12:30
To: Jonas Mårtensson <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Leeyoung <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

That’s a good proposal Jonas, we could go for a third branch called “open source” maybe. That’s something that can’t be considered standard, so I’m fine with both the options:

Option 1:

• Standard ITU
• Non standard

Option 2:

• Standard ITU
• Vendor specific
• Open source specific.

 

Regarding the use cases that’s the first and I agree with that , but I understood there is also the willingness from operators to open up to scenarios in which transport from vendor A interworks with transponder from vendor B (over vendor A,B,C,D…)

 

BR
Daniele 

 

From: Jonas Mårtensson <[e-mail]>
Sent: sabato 20 ottobre 2018 15:33
To: Daniele Ceccarelli <[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Leeyoung <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi all,

 

In addition to G.698.2 and ITU-T, what about referring to transponder interoperability specifications from other organizations, e.g. the Open ROADM MSA (100G DP-QPSK with Staircase FEC) and upcoming OIF 400ZR (400G DP-16QAM with Hamming SD-FEC + Staircase HD-FEC)?

 

Daniele, the scope defined in the draft under discussion is “to provide a Yang data model, which can be utilized by an MDSC to collect states of WSON impairment data from the Transport PNCs to enable impairment-aware optical path computation”. One use case that I see is computing all-optical paths between two transponders from vendor A over vendor B (+C+D+…) optical domains.

 

/Jonas

 

From: Daniele Ceccarelli <[e-mail]>
Sent: den 19 oktober 2018 21:25
To: Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; Leeyoung <[e-mail]>; Jonas Mårtensson <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

That should be the approach and I’m happy to see quite some alignment on that.

As Gert pointed out RFC7581 “provides a switch that enables non-standard implementations, but does not define them”. That is fine, it’s the switch we are talking about. That allows us continue working standard application codes as well as defining new non it code points.

 

--- end of chair statement and start of contributor mode

 

I wonder whether here we are speaking about vendor specific code points or rather operator specific code points.
if we speak about vendor specific code points this means that we most likely end up with Vendor 1 supporting code points A,B,C and vendor 2 supporting D,E,F.

IMHO it is pointless to have vendor specific code points if the final scope is having equipment from vendor A interwork with equipment form vendor B. Why a standard way of configuring proprietary parameters is needed at all?

 

What OTOH would be useful is a set of agreed code points that allow an operator to have two equipments from different vendors interwork in a non ITU-standard way.

 

BR
Daniele 

 

From: CCAMP <[e-mail]> On Behalf Of Beller, Dieter (Nokia - DE/Stuttgart)
Sent: venerdì 19 ottobre 2018 17:51
To: Leeyoung <[e-mail]>; Jonas Mårtensson <[e-mail]>; Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[e-mail]>
Cc: [e-mail]
Subject: Re: [CCAMP] I-D Action: draft-lee-ccamp-wson-impairment-yang-00.txt

 

Hi Young, all,

I think that we need both, the G.698.2 application codes, which are standardized (standardized operational modes), and vendor-specific operational modes.

Operational modes represent optical transponder settings which have to be the same for the two optical transponders terminating a photonic tunnel or segment
in case the tunnel includes 3R regenerators.

The vendor-ID attribute should be of type string. We can further discuss this in Bangkok.


Thanks,
Dieter

-- 
================================================================
Always remember that you are unique...just like everyone else...