CCAMP Session IETF 99

Thursday, July 20, 2017(CEST)

15:50-17:50 – Afternoon Session II

Presentation Start Time     Duration        Information        

0 15:50 10       

Title: Administrivia - WG Status - Reporting on WG drafts not being presented

Draft:        

Presenter: Chairs

1              16:00         10       

Title: A framework for Management and Control of DWDM optical interface parameters

Draft:https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06

Presenter: Ruediger Kunze

Jan Kundrat: Editorial change, the text refers to a “yellow” triangle. Please remove it. Daniele Ceccarelli: Thanks for intermediate versions. Readability OK now.

[Poll] Does anyone object moving the draft to WG LC? No one.

Fatai Zhang: please check if you use RFC language, if not please remove section 1.1

2 16:10 0

Title: A Yang Data Model for WSON Optical Networks and tunnels

Draft: https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-07

Draft: https://tools.ietf.org/html/draft-lee-ccamp-wson-tunnel-model-01

Presenter: Young Lee

*draft presented in the joint YANG session (see TEAS session II)

3                 16:10        10       

Title:        Info model and information encoding for WSON with impairments validation

Draft: https://tools.ietf.org/html/draft-ietf-ccamp-wson-iv-info-05

Draft: https://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-08

Presenter: Giovanni Martinelli

(regarding the first draft)

Dieter Beller: What is the added value of defining the optical parameters without having a model for optical feasibility calculation? Still unresolved issue in my opinion.

Giovanni M.: The parameters have been discussed with the ITU-T several times. There are refences to ITU-T documents in the draft.

Dieter B.: The problem is not lack of reference but lack of model to guarantee optical feasibility.

Gabriele Galimberti: The document allows anyone to use the parameters (e.g. by a controller) and defines how to exchange them. The document does not define them nor how to use them.

Young Lee: I agree with Gabriele, this draft adds additional attributes for path computation. 

Giovanni M.: We have also split the document and thrown away those not defined in ITU. 

Julien Meuric: Everyone acks it is not the full solution to the big problem, but it remains useful and required.

Dieter B.: Is the set of optical impairments parameters complete? 

Giovanni M.: It is complete according to the scope of the document. See section 3 of the document.

(regarding the second draft):

Authors believe it is ready for WG adpoption (still open points and encoding...)

Sergio Belotti: (regarding first draft). There is an uncompleted section (Section 5.4).

Giovanni: It is an issue, without many content, and we will continue working on it. 

4                 16:20        10       

Title:        A framework and YANG model for Management and Control of microwave and millimeter wave interface parameters

Draft:        https://tools.ietf.org/html/draft-ietf-ccamp-microwave-framework-01

Draft:        https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-01

Presenter: Jonas Ahlberg

Daniele C.: Congratulations to you and the team for the award at the hackathon. I have a comment from Lou to try to make another effort about what can be generalized. The microwave technology has a variable bit-rate but there are also other technologies like e.g. elastic optics. We can add some notes in the framework indicating that the considerations are applicable also to other technologies. Little bit more changes are expected on the YANG model.

Two options for the model: one is to have a new document with the generic part and leave the technology-specific parts here or to keep the generic and mw-specific parts in the current document but clearly separated.

Amy Y.: Personally, prefer the second option. 

Oscar G.: Is there any reference to ETSI specification in the YANG model parameters? 

Jonas A.: We have referred to a set of documents (each of which often referring each other), but not indicated in detail where each parameter comes from. 

Giovanni M.: Something that could be generalized could be the protection part (manual, force switch) and priority support.

Jonas A.: Will need to consider different protection mechanisms. 

6                 16:30        15       

Title:        Transport Northbound Interface Use Cases and Gap Analysis UC1

Draft:        https://tools.ietf.org/html/draft-tnbidt-ccamp-transport-nbi-use-cases-02

Draft:        https://tools.ietf.org/html/draft-tnbidt-ccamp-transport-nbi-analysis-uc1-00

Presenter: Italo Busi

Jan Kundrat: Are you considering also OpenROADM(No)

Daniele C.: We could help you with liaisons and communications once the draft are WG documents. How did you provide feedbacks to TEAS?

Italo B: contributions to the design team call.

Fatai Z.: Some coordination with Igor's draft is needed to avoid conflicts on the NBI.

Italo: will do

Sergio: Regarding OpenROADM, that is a device model while our scope is a network model. 

Daniele C.:[poll] How many have read the use cases draft? almost everyone. 

How many think the WG should adopt this work? almost everyone. 

7                 16:45        10       

Title:        Flexigrid and flexigrid media channel YANG models

Draft:        https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-yang-05

Draft:        https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-media-channel-yang-00

Presenter:       Oscar Gonzalez de Dios

Jan K.: Same values of M and N could be used to identify incompatible channels. Was it ever considered to use Ghz or Thz to identify the center of the channel of the channel width?

Gabriele G.: We are using M and N first because this is in line with ITU-T and second because using THz or lambda we may end up in rounding issues and the frequency can be misinterpreted (5 digits after the comma are not enough). Maybe you are thinking about the OpenROADM model which I disagree with because it has this issue.

Dieter B: M and N parameters are well defined in ITU-T recommendation G694.1, which should apply here. G694.1 should be added as normative reference.

Gabriele G.: Moreover, N is still valid in case you add future granularities (e.g. 3.125Ghz) or apply it to fixed grid (e.g. 50Ghz).

Yuji T.: Can you please clarify terminology in the draft when speaking about Media Channel and Network Media Channel?

Oscar G.: Terminology is discussed in the framework document(RFC7698) and in ITU.

Yuji T.: This should be aligned with ITU-T recommendation G.872, and with a new work in ITU-T called G.media.

Oscar G.: In IETF we define how we abstact those data plane constructs.

Young L.: Good base for WG adoption. The names need to be aligned with TE-Tunnel mode.

Haomian Z.: Terminology alignment occurred between flex grid and RFC7698(framework). We need to align also with other IETF models.

Dieter B.: Please reconsider the definition of connectivity matrix in the TEAS TE Topology. Extensions should be aligned with the connectivity matrix definition in the base model. In addition, it should be read-only for WDM networks.

Young L.: Late changes we need to align with. We also still need application codes. Authors will align offline with TE Topology authors.   

8                 16:55        10       

Title: Signaling extensions for Media Channel sub-carriers configuration in SSON in LSC Optical Line Systems.

Draft:  https://tools.ietf.org/html/draft-ggalimber-ccamp-flexigrid-carrier-label-01

Presenter:        Gabriele Galimberti

Note: Given the interesting discussion raised by the presentation Gabriele decided to use the time allocated to slots 9 and 10 to continue the discussion related to slot 8.

Qilei Wang: Could you explain the relationship between sub-carrier and OTSi? In my understanding, one OTSi can contain two sub-carriers.

Gabriele Galimberti: ITU-T defines that one OTSi can have two or more sub-carriers. In the example, the payload is shared between two OTSi. If one OTSi is lost, all the payload is lost. It is a sort of inverse multiplexing, but is detailed implementation.

Dieter Beller: Why the change from experimental to informational? Also, I wonder whether CCAMP is the right place to standardize proprietary solution.

Gabriele Galimberti: It is about experimental, but I think this can also inform what the solution could solve the problem of multi-carrier transponder.

Dieter Beller: A product from which vendor?

Gabriele: My vendor.

Daniele Ceccarelli: This is a perfect example for experimental. It is something not standard, but with real code.

Gabriele Galimberti: No problem to move back to experimental

Julien Meuric: As operator, I would be happy to have other proprietary proposals joining this initiative, because it could be a way to turn into a standard track document. Considering I am actually deploying this multi-vendor alien wavelength, this is required to stop doing manual or multiple-step operations. I support the work, we would like to see multiple vendors work on this topic.

Daniele Ceccarelli: How would you like to see this progress? Experimental?

Haomian Zheng: Explicit data plane standard to support multi vendor should be required, however we don't have it yet. If every vendor bring their own implementation, it still cannot support operator's requirements.

Gabriele Galimberti: We are open to hear from other vendors’ solution on SSON. 

Yuji Tochio: This draft defines modulation ID inside, it needs to have clear references for the modulation ID.

Gabriele Galimberti: I list a lot of modulation formats in the draft, probably it is not exhaustive. Probably it is not the best to represent the parameters. We have a number for each modulation format. I am open, no problem to change the order.

Italo Busi: Q6/15 in ITU-T is working on a standard data plane, it is better to wait for data plane standard before having control plane standard.

Gabriele Galimberti: The market is not waiting.

Sergio Belotti: You said before no more experimental but this is proto. Question is that whether IETF has to standardize company proto even it is supported by operators.

Daniele Ceccarelli： An experimental draft doesn’t mean standardization. You cannot be informational because you are defining TLVs. Let’s progress with the assumption that this document goes back to experimental status.

Giovanni Martinelli: For multi-vendor issue, ITU-T does not define interoperable standard. Something need to be moved even though the data plane standard is not available now. For modulation formats, we can have a table to refer. Changing encoding give you changing modulation format.

Julien Meuric: An informative or experimental draft is better than nothing.  

9                 17:05        10       

Title:        Extension to LMP for DWDM Optical Line Systems to manage the application code of optical interface parameters in DWDM application

Draft:        https://tools.ietf.org/html/draft-dharinigert-ccamp-dwdm-if-lmp-04

Draft:        https://tools.ietf.org/html/draft-ggalimbe-ccamp-flex-if-lmp-02

Presenter:        Gabriele Galimberti

(skipped to have more time for previous discussion)

10                 17:15        10       

Title:        A YANG model to manage the optical interface parameters for an external transponder in a WDM network and optical paramenter in a WDM network

Draft:        https://tools.ietf.org/html/draft-dharini-ccamp-dwdm-if-param-yang-02

Draft:        https://tools.ietf.org/html/draft-galimbe-ccamp-iv-yang-03

Presenter:        Gert Grammel

(skipped to have more time for previous discussion)

11                 17:25        10       

Title:        GMPLS Routing and Signaling Framework for B100G

Draft:        https://tools.ietf.org/html/draft-merge-ccamp-otn-b100g-fwk-01

Presenter:        Qilei Wang

Yuji Tochio: -01 has three flexE use cases, there seems to be new for 4.5, please handle it carefully.

Qilei: We will check. 

12                 17:35        15        Title:        GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)

Draft:        https://tools.ietf.org/html/draft-izh-ccamp-flexe-fwk-03

Presenter:        Loa Andersson

Deborah Brungard: in the diagram, what's switching in the middle box?

Loa Andersson: FlexE is not a switching technology. 

Deborah Brungard: as individual, FlexE calendar slot is not switching, but terminiated. LSP as an example, FlexE , show the architeture, FlexE is purly a link, terminated inside. FlexE then just a encoding of the link. It's nothing to be switched

Andrew Malis: two different approaches, GMPLS approach, label is not exist on the data packet; MPLS apporach, labels on the data packet  

Yuji Tochio: Is the FlexE sub link differnt from FlexE clinet (in OIF IA)?        

Loa Andersson: FlexE sub-link is a link with one Ethernet interface at each end and FlexE client between them. 

Mach Chen: We do not support FlexE switching. FlexE terminates at each hop. The FlexE frame will be recovered to Ethernet/MPLS packet, then transmitted to the next hop. It is just like what is defined in the OIF FlexE IA.

Loa Andersson: We are setting up an MPLS LSP.configure the undelying and sub link by GMPLS signaling and routing.

Deborah Brungard: it's not controllable, it's atuomatic. talk to the ITU-T people. 

13                 17:50        0       

Title: ISIS Extensions for Flexible Ethernet (if time permits)

Draft:        https://tools.ietf.org/html/draft-zcdc-isis-flexe-extention-01

Presenter:        Mach Chen

Daniele Ceccarelli: once we have understood what to switch, I would say this is a CCAMP draft, not ISIS draft

Julien Meuric: We have done IGP extension in CCAMP. But I think this draft doesn't match. 

Daniele Ceccarelli: Need to make it clear what you want to advertise. The draft is talking about changing the switching capability descriptor. 

Mach: OK