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

[Julien Meuric <[e-mail]>]

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 - [e-mail]:
>
> 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:[e-mail]]
> *Sent:* lunedì 12 marzo 2018 14:31
>
>  
>
> 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.
>
>      
>
>     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:[e-mail]] *On Behalf Of
>     *Giovanni Martinelli (giomarti)
>     *Sent:* lunedì 12 marzo 2018 09:58
>
>      
>
>     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
>         <[e-mail] <mailto:[e-mail]>> 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:[e-mail]] *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
>             and draft-ietf-ccamp-wson-iv-info
>
>              
>
>             Cheers
>
>             G
>
>              
>
>
>
>
>
>                 On 9 Mar 2018, at 10:04, Dieter Beller
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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
>
>                      
>