Subject: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 6 Mar 2018 17:41:01 +0000

Working group,

This starts a two weeks poll on making  draft-martinelli-ccamp-wson-iv-encode-09 a CCAMP working group document.
Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for  your reply, mandatory for the "not support" and nice to have for the "support".
Please note that the IPR declarations was carried out against version -08 and this is version -09 but there is no change in the content of the document, just a date refresh. No IPR was disclosed against this document.
The polling will end on Tuesday march 20th.

Thanks,
Daniele & Fatai

---

From: Leeyoung <[email-masked]>
Date: Tue, 6 Mar 2018 17:42:27 +0000

Yes/support.

Young (co-author)

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Tuesday, March 06, 2018 11:41 AM
To: CCAMP ([email-masked]) <[email-masked]>
Subject: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Working group,

Thanks,
Daniele & Fatai

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Wed, 7 Mar 2018 16:02:59 +0000

yes/support

as author

Cheers
G

On 6 Mar 2018, at 18:41, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:

Working group,

Thanks,
Daniele & Fatai

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Dieter Beller <[email-masked]>
Date: Fri, 9 Mar 2018 10:04:22 +0100

Hi all,

no/do not support

Reasoning: the definition of optical impairment parameters and the
encoding of those is useless without the definition of a
computational model for

optical impairment validation (IV) in the context of end-to-end path
computation in a WDM network.

Computational models are typically vendor-specific and the draft
does therefore not provide a solution to the problem of
optical impairment validation

(computation of paths where optical impairment constraints need to
considered.) The same applies to the related drafts addressing IV.

Thanks,

Dieter

On 06.03.2018 18:41, Daniele Ceccarelli
wrote:

Working group,

This starts a two weeks poll on making
draft-martinelli-ccamp-wson-iv-encode-09 a CCAMP working
group document.

Please send email to the list indicating
"yes/support" or "no/do not support" and a motivation for
your reply, mandatory for the "not support" and nice to have
for the "support".

Please note that the IPR declarations was
carried out against version -08 and this is version -09 but
there is no change in the content of the document, just a
date refresh. No IPR was disclosed against this document.

Thanks,

Daniele
& Fatai

[email-masked]

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 9 Mar 2018 09:43:53 +0000

agree on the fact that this comment apply to other drafts, rather than this one, in particular: RFC6566 and draft-ietf-ccamp-wson-iv-info

Cheers
G

On 9 Mar 2018, at 10:04, Dieter Beller <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

no/do not support

Reasoning: the definition of optical impairment parameters and the encoding of those is useless without the definition of a computational model for
optical impairment validation (IV) in the context of end-to-end path computation in a WDM network.
Computational models are typically vendor-specific and the draft does therefore not provide a solution to the problem of optical impairment validation
(computation of paths where optical impairment constraints need to considered.) The same applies to the related drafts addressing IV.

Thanks,
Dieter

On 06.03.2018 18:41, Daniele Ceccarelli wrote:
Working group,

Thanks,
Daniele & Fatai

---

From: Leeyoung <[email-masked]>
Date: Fri, 9 Mar 2018 20:09:37 +0000

Hi all,

The scope of this document is to enhance OSPF to carry LSA that includes impairment data. How to use these data is up to head end node or external PCE to compute the path that is impairment-aware.
RFC 6566 explains this context well. See Section 5 of RFC 6566 that discusses the computation models. Of course, the computation algorithm as to how to use impairment info is the secret source for each vendor, which is not what we talk about in this draft. We only say these impairment data is needed to enhance the RWA optical path calculation.

Hope this explains.

Thanks.
Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Giovanni Martinelli (giomarti)
Sent: Friday, March 09, 2018 3:44 AM
To: Dieter Beller <[email-masked]>
Cc: CCAMP ([email-masked]) <[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 9 Mar 2018 21:19:20 +0000

Thanks a lot for the clear explanation Young,

I fully agree with You.

Regards,

Gabriele

[ttp://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[email-masked]<mailto:[email-masked]>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

From: CCAMP <[email-masked]> on behalf of Leeyoung <[email-masked]>
Date: Friday, 9 March 2018 at 21:09
To: "Giovanni Martinelli (giomarti)" <[email-masked]>, Dieter Beller <[email-masked]>
Cc: "CCAMP ([email-masked])" <[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Hi all,

Hope this explains.

Thanks.
Young

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Mon, 12 Mar 2018 09:37:54 +0100

Hi Young, all,

based on what you wrote below, I conclude that the defined
impairment parameters are insufficient for IV and vendor-specific
(proprietary) extensions are

needed anyway (e.g. opaque OSPF-TE LSA extensions). That's why this
draft as well as the related drafts do not provide a solution to the
problem of optical IV.

These drafts are wrongly suggesting that such a solution exists.

Thanks,

Dieter

On 09.03.2018 21:09, Leeyoung wrote:

Hi
all,

The
scope of this document is to enhance OSPF to carry LSA that
includes impairment data. How to use these data is up to
head end node or external PCE to compute the path that is
impairment-aware.

RFC
6566 explains this context well. See Section 5 of RFC 6566
that discusses the computation models. Of course, the
computation algorithm as to how to use impairment info is
the secret source for each vendor, which is not what we talk
about in this draft. We only say these impairment data is
needed to enhance the RWA optical path calculation.

Hope
this explains.

Thanks.

Young

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Giovanni Martinelli (giomarti)

Subject: Re: [CCAMP] Poll for adoption -
draft-martinelli-ccamp-wson-iv-encode-09

agree on the fact that this comment apply
to other drafts, rather than this one, in particular: RFC6566
and draft-ietf-ccamp-wson-iv-info

Cheers

G

On 9 Mar 2018, at 10:04, Dieter
Beller <[email-masked]>
wrote:

Hi
all,

no/do not support

Reasoning: the
definition of optical impairment parameters and
the encoding of those is useless without the
definition of a computational model for

optical impairment
validation (IV) in the context of end-to-end path
computation in a WDM network.

Computational models
are typically vendor-specific and the draft does
therefore not provide
a solution to the problem of optical impairment
validation

(computation of paths
where optical impairment constraints need to
considered.) The same applies to the related
drafts addressing IV.

Thanks,

Dieter

On
06.03.2018 18:41, Daniele Ceccarelli wrote:

Working
group,

This
starts a two weeks poll on making
draft-martinelli-ccamp-wson-iv-encode-09 a CCAMP
working group document.

Please
send email to the list indicating "yes/support" or
"no/do not support" and a motivation for  your
reply, mandatory for the "not support" and nice to
have for the "support".

Please
note that the IPR declarations was carried out
against version -08 and this is version -09 but
there is no change in the content of the document,
just a date refresh. No IPR was disclosed against
this document.

The
polling will end on Tuesday
march 20th.

Thanks,

Daniele
& Fatai

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 12 Mar 2018 08:57:36 +0000

Dieter,

looks like you are opening again a discussion we had a while back.
If you look at draft-ietf-ccamp-wson-iv-info there’s clear statements about this and it was formalizing the output of Join ITU/Ccamp meeting hold in Orlando at IETF86. If you like we can sum up again the conclusion but probably you may first want to provide specific comments on draft-ietf-ccamp-wson-iv-info, it’s a WG draft and its open for improvements.

This specific draft draft-martinelli-ccamp-wson-iv-encode-09 just provide encoding for defitions within draft-ietf-ccamp-wson-iv-info where list of parameters was provide by ITU liason referred in the document.

Cheers
G

On 12 Mar 2018, at 09:37, Dieter Beller <[email-masked]<mailto:[email-masked]>> wrote:

Hi Young, all,

based on what you wrote below, I conclude that the defined impairment parameters are insufficient for IV and vendor-specific (proprietary) extensions are
needed anyway (e.g. opaque OSPF-TE LSA extensions). That's why this draft as well as the related drafts do not provide a solution to the problem of optical IV.
These drafts are wrongly suggesting that such a solution exists.

Thanks,
Dieter

Hope this explains.

Thanks.
Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Giovanni Martinelli (giomarti)
Sent: Friday, March 09, 2018 3:44 AM
To: Dieter Beller <[email-masked]><mailto:[email-masked]>
Cc: CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Mon, 12 Mar 2018 10:15:16 +0000

Hi Daniele, WG

no/do not support

I share Dieter's motivation

Thanks
Sergio

From: CCAMP [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Friday, March 9, 2018 10:04 AM
To: Daniele Ceccarelli <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 12 Mar 2018 11:40:34 +0000

I tend to agree with Giovanni here.

The discussion is not about the draft being polled, which is the encoding of an information described by a WG document.
The discussion seems to be focused on a document that the working group decide to work on. Such work is still in progress and hence open to discussion and refinement.

BR
Daniele

Sent: lunedì 12 marzo 2018 09:58

Dieter,

Cheers
G

Hi Young, all,

Thanks,
Dieter

Hope this explains.

Thanks.
Young

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Mon, 12 Mar 2018 14:30:54 +0100

Hi Daniele,

your arguments seem to be more IETF process-oriented and I
understand those.

My technical arguments are indeed not new and I have raised my
concerns at almost every CCAMP meeting in the last couple of years
as well as on the

mailing list.

It looks like my technical arguments are constantly ignored by the
folks in the WG who are working on these drafts while they must be
aware that what

they are defining is incomplete and therefore it is NOT possible
to perform IV for an end-to-end path in a WDM network. Parameters
and their encoding

can only be defined if a standardized and accurate computational
model for IV is defined too, which is most likely not going to
happen.

Thanks,

Dieter

On 12.03.2018 12:40, Daniele Ceccarelli
wrote:

The discussion is not about the draft being
polled, which is the encoding of an information described by
a WG document.

The discussion seems to be focused on a
document that the working group decide to work on. Such work
is still in progress and hence open to discussion and
refinement.

BR

Daniele

From: CCAMP [mailto:[email-masked]]
On Behalf Of Giovanni Martinelli (giomarti)

To: Dieter Beller
<[email-masked]>

Cc: CCAMP ([email-masked])
<[email-masked]>

Dieter,

looks like you are opening again a
discussion we had a while back.

If you look
at draft-ietf-ccamp-wson-iv-info there’s clear statements
about this and it was formalizing the output of Join
ITU/Ccamp meeting hold in Orlando at IETF86. If you like
we can sum up again the conclusion but probably you may
first want to provide specific comments on
draft-ietf-ccamp-wson-iv-info, it’s a WG draft and its
open for improvements.

This specific
draft draft-martinelli-ccamp-wson-iv-encode-09 just
provide encoding for defitions within
draft-ietf-ccamp-wson-iv-info where list of parameters was
provide by ITU liason referred in the document.

Cheers

G

On 12 Mar 2018, at 09:37, Dieter
Beller <[email-masked]>
wrote:

Hi
Young, all,

based on what you
wrote below, I conclude that the defined
impairment parameters are insufficient for IV
and vendor-specific (proprietary) extensions are

needed anyway (e.g.
opaque OSPF-TE LSA extensions). That's why this
draft as well as the related drafts do not
provide a solution to the problem of optical IV.

These drafts are
wrongly suggesting that such a solution exists.

Thanks,

Dieter

On
09.03.2018 21:09, Leeyoung wrote:

Hi all,

The scope of this
document is to enhance OSPF to carry LSA that
includes impairment data. How to use these
data is up to head end node or external PCE to
compute the path that is impairment-aware.

RFC 6566 explains this
context well. See Section 5 of RFC 6566 that
discusses the computation models. Of course,
the computation algorithm as to how to use
impairment info is the secret source for each
vendor, which is not what we talk about in
this draft. We only say these impairment data
is needed to enhance the RWA optical path
calculation.

Hope this explains.

Thanks.

Young

From: CCAMP
[mailto:[email-masked]] On
Behalf Of Giovanni
Martinelli (giomarti)

Sent: Friday,
March 09, 2018 3:44 AM

To: Dieter

Cc: CCAMP
([email-masked]) <[email-masked]>

Subject: Re:
[CCAMP] Poll for adoption -
draft-martinelli-ccamp-wson-iv-encode-09

agree
on the fact that this comment apply to other
drafts, rather than this one, in
particular: RFC6566
and draft-ietf-ccamp-wson-iv-info

Cheers

G

On 9 Mar 2018,
at 10:04, Dieter Beller <[email-masked]>
wrote:

Hi
all,

no/do
not support

Reasoning:
the definition of optical impairment
parameters and the encoding of those
is useless without the definition of
a computational model for

optical
impairment validation (IV) in the
context of end-to-end path
computation in a WDM network.

Computational
models are typically vendor-specific
and the draft does therefore not provide
a solution to the problem of optical
impairment validation

(computation
of paths where optical impairment
constraints need to considered.) The
same applies to the related drafts
addressing IV.

Thanks,

Dieter

On
06.03.2018 18:41, Daniele Ceccarelli
wrote:

Working
group,

This
starts a two weeks poll on making
draft-martinelli-ccamp-wson-iv-encode-09
a CCAMP working group document.

Please
send email to the list indicating
"yes/support" or "no/do not support"
and a motivation for  your reply,
mandatory for the "not support" and
nice to have for the "support".

Please
note that the IPR declarations was
carried out against version -08 and
this is version -09 but there is no
change in the content of the document,
just a date refresh. No IPR was
disclosed against this document.

The

Thanks,

Daniele
& Fatai

CCAMP mailing list

[email-masked]

CCAMP
mailing list

[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 12 Mar 2018 13:46:02 +0000

Hi Dieter, all,

yes, that’s the comment I can make from a process point of view, as well as noticing that this work is supported by three major vendors and two operators active in CCAMP (things that can’t be ignored and that will be taken into account, together with other inputs, by the chairs when deciding whether to adopt the draft or not).

From an individual point of view I consider this impasse a bit frustrating, because the secret sauce will always be there and I don’t understand why we shouldn’t try to offer the service providers to choose among:

  *   A wonderful single vendor solution with secret parameters and secret algorithms that allows reaching supreme performances.
  *   A decent acceptable interoperable solution in which a compromise is made accepting to work on a set of agreed parameters that each vendor can use as input to its secret sauce.

The full set of parameters will never be agreed (long time == never), hence I don’t see harmful to agree on a set of parameters and a standard way of encoding them to be used by different algorithms to find something interoperable which is for sure non optimal but decent.

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: lunedì 12 marzo 2018 14:31
To: Daniele Ceccarelli <[email-masked]>
Cc: Giovanni Martinelli (giomarti) <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Hi Daniele,

your arguments seem to be more IETF process-oriented and I understand those.

My technical arguments are indeed not new and I have raised my concerns at almost every CCAMP meeting in the last couple of years as well as on the
mailing list.

It looks like my technical arguments are constantly ignored by the folks in the WG who are working on these drafts while they must be aware that what
they are defining is incomplete and therefore it is NOT possible to perform IV for an end-to-end path in a WDM network. Parameters and their encoding
can only be defined if a standardized and accurate computational model for IV is defined too, which is most likely not going to happen.

Thanks,
Dieter

On 12.03.2018 12:40, Daniele Ceccarelli wrote:
I tend to agree with Giovanni here.

BR
Daniele

Dieter,

Cheers
G

Hi Young, all,

Thanks,
Dieter

Hope this explains.

Thanks.
Young

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Mon, 12 Mar 2018 14:08:20 +0000

to me this is a very good summary.

Cheers
G

On 12 Mar 2018, at 14:46, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dieter, all,

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: lunedì 12 marzo 2018 14:31
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Cc: Giovanni Martinelli (giomarti) <[email-masked]<mailto:[email-masked]>>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Hi Daniele,

Thanks,
Dieter

BR
Daniele

Dieter,

Cheers
G

Hi Young, all,

Thanks,
Dieter

Hope this explains.

Thanks.
Young

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 12 Mar 2018 14:57:16 +0000

Fully agree with Daniele, also because there are activities in the optical community demonstrating that.

Best Regards,

Gabriele

Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl

From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli <[email-masked]>
Date: Monday, 12 March 2018 at 14:46
To: Dieter Beller <[email-masked]>
Cc: "CCAMP ([email-masked])" <[email-masked]>
Subject: Re: [CCAMP] Poll for adoption - draft-martinelli-ccamp-wson-iv-encode-09

Hi Dieter, all,

From an individual point of view I consider this impasse a bit frustrating, because the secret sauce will always be there and I don’t understand why we shouldn’t try to offer the service providers to choose among:
-          A wonderful single vendor solution with secret parameters and secret algorithms that allows reaching supreme performances.
-          A decent acceptable interoperable solution in which a compromise is made accepting to work on a set of agreed parameters that each vendor can use as input to its secret sauce.

BR
Daniele

Hi Daniele,

Thanks,
Dieter

BR
Daniele

Dieter,

Cheers
G

Hi Young, all,

Thanks,
Dieter

Hope this explains.

Thanks.
Young

Cheers
G

Hi all,

no/do not support

Thanks,
Dieter

Thanks,
Daniele & Fatai

CCAMP mailing list

---

From: Julien Meuric <[email-masked]>
Date: Mon, 12 Mar 2018 16:14:26 +0100

Hi all,

I agree with Daniele. The requirements one may have on transparency from
Madrid to Warsaw should not be used to prevent interoperability where
high-end systems are over-sized. Furthermore, adding a regeneration from
time to time could be an acceptable price to pay to enhance
interoperability: this is the kind of trade off urging for initiatives
like OpenROADM.

@Dieter:
The polled I-D does two things:
- identify some optical parameter sets (which you may enhance if adopted),
- specify the sub-TLV structure to carry these; thus creating
opportunities to add codepoints for a "secret photon spin", to bring
implementers (including stack vendors and open source projects) provide
ready-to-carry OSPF stacks, and to build compatible protocol analyzers
(which are particularly useful).
Whatever your disagreement with the rough consensus on the former, you
should be interested by the latter.

Moreover, even if optical feasibility used to be opaque, there are now
open initiatives (like "Telecom Infrastrucure Project) publicizing code
to implement that feature. It is part of the IETF's duty to provide
standard means to convey corresponding information in OSPF.

As a result, in case it is not clear, I support the adoption of the I-D.

Thanks,

Julien

Mar. 12, 2018 - [email-masked]:
>
> Hi Dieter, all,
>
>  
>
> yes, that’s the comment I can make from a process point of view, as
> well as noticing that this work is supported by three major vendors
> and two operators active in CCAMP (things that can’t be ignored and
> that will be taken into account, together with other inputs, by the
> chairs when deciding whether to adopt the draft or not).
>
>  
>
> From an individual point of view I consider this impasse a bit
> frustrating, because the secret sauce will always be there and I don’t
> understand why we shouldn’t try to offer the service providers to
> choose among:
>
>   * A wonderful single vendor solution with secret parameters and
>     secret algorithms that allows reaching supreme performances.
>   * A decent acceptable interoperable solution in which a compromise
>     is made accepting to work on a set of agreed parameters that each
>     vendor can use as input to its secret sauce.
>
>  
>
> The full set of parameters will never be agreed (long time == never),
> hence I don’t see harmful to agree on a set of parameters and a
> standard way of encoding them to be used by different algorithms to
> find something interoperable which is for sure non optimal but decent.
>
>  
>
> BR
> Daniele 
>
>  
>
>  
>
> *From:*Dieter Beller [mailto:[email-masked]]
> *Sent:* lunedì 12 marzo 2018 14:31
>
>  
>
> Hi Daniele,
>
> concerns at almost every CCAMP meeting in the last couple of years as
> well as on the
> mailing list.
>
> they are defining is incomplete and therefore it is NOT possible to
> perform IV for an end-to-end path in a WDM network. Parameters and
> their encoding
> can only be defined if a standardized and accurate computational model
> for IV is defined too, which is most likely not going to happen.
>
>
> Thanks,
> Dieter
>
>     The discussion is not about the draft being polled, which is the
>     encoding of an information described by a WG document.
>
>     The discussion seems to be focused on a document that the working
>     group decide to work on. Such work is still in progress and hence
>     open to discussion and refinement.
>
>      
>
>     BR
>     Daniele 
>
>      
>
>     *From:*CCAMP [mailto:[email-masked]] *On Behalf Of
>     *Giovanni Martinelli (giomarti)
>     *Sent:* lunedì 12 marzo 2018 09:58
>
>      
>
>     Dieter,
>
>      
>
>     If you look at draft-ietf-ccamp-wson-iv-info there’s clear
>     statements about this and it was formalizing the output of Join
>     ITU/Ccamp meeting hold in Orlando at IETF86. If you like we can
>     sum up again the conclusion but probably you may first want to
>     provide specific comments on draft-ietf-ccamp-wson-iv-info, it’s a
>     WG draft and its open for improvements.
>
>      
>
>     This specific draft draft-martinelli-ccamp-wson-iv-encode-09 just
>     draft-ietf-ccamp-wson-iv-info where list of parameters was provide
>     by ITU liason referred in the document.
>
>      
>
>     Cheers
>
>     G
>
>      
>
>      
>
>         On 12 Mar 2018, at 09:37, Dieter Beller
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>          
>
>         Hi Young, all,
>
>         impairment parameters are insufficient for IV and
>         vendor-specific (proprietary) extensions are
>         needed anyway (e.g. opaque OSPF-TE LSA extensions). That's why
>         this draft as well as the related drafts do not provide a
>         solution to the problem of optical IV.
>             The scope of this document is to enhance OSPF to carry LSA
>             that includes impairment data. How to use these data is up
>             to head end node or external PCE to compute the path that
>             is impairment-aware. 
>
>             RFC 6566 explains this context well. See Section 5 of RFC
>             6566 that discusses the computation models. Of course, the
>             the secret source for each vendor, which is not what we
>             talk about in this draft. We only say these impairment
>             data is needed to enhance the RWA optical path calculation.
>
>              
>
>             Hope this explains.
>
>              
>
>             Thanks.
>
>             Young
>
>              
>
>             *From:* CCAMP [mailto:[email-masked]] *On Behalf
>             Of *Giovanni Martinelli (giomarti)
>             *Sent:* Friday, March 09, 2018 3:44 AM
>
>              
>
>             agree on the fact that this comment apply to other drafts,
>             rather than this one, in particular: RFC6566
>                 On 9 Mar 2018, at 10:04, Dieter Beller
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                  
>
>                 Hi all,
>
>                 no/do not support
>
>                 Reasoning: the definition of optical impairment
>                 parameters and the encoding of those is useless
>                 without the definition of a computational model for
>                 optical impairment validation (IV) in the context of
>                 end-to-end path computation in a WDM network.
>                 Computational models are typically vendor-specific and
>                 the draft does therefore *not *provide a solution to
>                 the problem of optical impairment validation
>                 (computation of paths where optical impairment
>                 constraints need to considered.) The same applies to
>                 the related drafts addressing IV.
>
>
>                 Thanks,
>                 Dieter
>
>
>
>
>                     "yes/support" or "no/do not support" and a
>                     motivation for  your reply, mandatory for the "not
>                     support" and nice to have for the "support".
>
>                     Please note that the IPR declarations was carried
>                     out against version -08 and this is version -09
>                     but there is no change in the content of the
>                     document, just a date refresh. No IPR was
>                     The polling will end on *Tuesday march 20th*.
>
>                      
>
>                     Thanks,
>
>                     Daniele & Fatai
>
>                      
>